The present invention relates to instrument driver software for instrumentation systems, and more particularly to an instrumentation driver software architecture for communicating with and controlling instruments in an instrumentation system.
An instrument is a device which collects data or information from an environment or unit under test and displays this information to a user. An instrument may also perform various data analysis and data processing on acquired data prior to displaying the data to the user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc., and the types of information which might be collected by respective instruments include voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others.
In the past, many instrumentation systems comprised individual instruments physically interconnected with each other. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems, the user interacts with software executing on the computer system through the computer""s video monitor rather than through a manually operated front panel to control one or more real world instruments. The software executing on the computer system can be used to simulate the operation of an instrument in software or to control or communicate with one or more real world instruments, these software created/controlled instruments being referred to as virtual instruments.
Therefore, modern instrumentation systems are moving from dedicated stand-alone hardware instruments such as oscilloscopes, digital multimeters, etc., to a concept referred to as virtual instrumentation. Virtual instrumentation comprises general purpose personal computers and workstations combined with instrumentation software and hardware to build a complete instrumentation system. In a virtual instrumentation system, a virtual instrument operating on a central computer controls the constituent instruments from which it acquires data which it analyzes, stores, and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use, and computerized instrumentation systems provide significant performance efficiencies over earlier systems for linking and controlling test instruments.
The various hardware interface options currently available for instrumentation systems can be categorized into various types, including IEEE 488-controlled instruments (GPIB instruments), VXI bus instruments, plug-in data acquisition (DAQ) boards, PCI bus and PXI bus instruments, and serial instruments, such as RS-232-controlled, USB, or IEEE 1394 instruments, among others. Background on these various hardware interface options is deemed appropriate.
The GPIB (general purpose interface bus) began as a bus designed by Hewlett-Packard in 1965, referred to as the Hewlett-Packard Interface Bus (HPIB), to connect their line of programmable instruments to their computers. National Instruments Corporation expanded the use of this bus to computers manufactured by companies other than Hewlett-Packard and hence the name General Purpose Interface Bus (GPIB) became more widely used than HPIB. The GPIB interface bus gained popularity due to its high transfer rates and was later accepted as IEEE standard 488-1975, and the bus later evolved to ANSI/IEEE standard 488.1-1987. In order to improve on this standard, two new standards were drafted, these being ANSI/IEEE 488.2-1987 and the SCPI (Standard Commands for Programmable Instruments) standard. The IEEE 488.2 standard strengthened the original standard by defining precisely how controllers and instruments communicated. The IEEE 488.2 standard removed ambiguities of the IEEE 488.1 standard by defining data formats, status reporting, a message exchange protocol, IEEE 488.2 controller requirements, and common configuration commands to which all IEEE 488.2 instruments must respond in a precise manner. Thus, the IEEE 488.2 standard created more compatible, more reliable systems that were simpler to program. In 1990, a new specification was developed referred to as the Standard Commands for Programmable Instruments (SCPI), which used the command structures defined in the IEEE 488.2 standard and formed a single, comprehensive programming command set that is used with any SCPI instrument. The SCPI standard simplified the programming process for manufacturers and users alike. Rather than having to learn a different command set for each instrument, the user could focus on solving the measurement tests of his or her application, thus decreasing programming time.
The VXI (VME eXtension for Instrumentation) bus is a platform for instrumentation systems that was first introduced in 1987 and was originally designed as an extension of the VME bus standard. The VXI standard has experienced tremendous growth and acceptance around the world and is used in a wide variety of traditional test and measurement and ATE applications. The VXI standard uses a mainframe chassis with a plurality of slots to hold modular instruments on plug-in boards. The VXI architecture is capable of interfacing with both message-based instruments and register-based instruments. A message-based instrument is an instrument which is controlled by a string of ASCII characters, whereas a register-based instrument is controlled by writing a bit stream of 1""s and 0""s directly to registers in the instrument hardware.
An instrumentation system using a data acquisition interface method typically includes transducers which sense physical phenomena from the process or unit under test and provide electrical signals to data acquisition hardware inside the computer system. The electrical signals generated by the transducers are converted into a form that the data acquisition board can accept, typically by signal conditioning logic positioned between the transducers and the data acquisition card in the computer system.
PCI (Peripheral Component Interconnect) bus instruments and PXI (PCI eXtensions for Instrumentation) instruments leverage off of the PCI bus found in mainstream computer systems. These instruments include a connector which is electrically compatible with the PCI bus. xe2x80x9cDesktop PCIxe2x80x9d instruments have a conventional PCI form factor for use in desktop PCs. The PXI instrumentation bus standard, promulgated by National Instruments, includes a CompactPCI mechanical form factor, is electrically compatible with the PCI bus, and includes extra signal definitions for instrumentation purposes.
A computer can also control an instrumentation system through a serial connection, such as the computer""s serial or RS-232 port, the USB (Universal Serial Bus), or the IEE 1394 or 1394.2 bus, referred to as Firewire. There are currently thousands of instruments with an RS-232 interface.
Due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it is often necessary for a user to develop a program to control respective instruments in the desired instrumentation system. Therefore, implementation of such systems frequently requires the involvement of a programmer to develop software for acquisition, analysis and presentation of instrumentation data.
The software architecture for an instrumentation system, such as a virtual instrumentation system, comprises several components. The top level of the software architecture typically comprises an application program used for high level control of the virtual instrument. Examples of high level application programs for instrumentation control are LabVIEW, LabWindows CVI, and ComponentWorks from National Instruments Corp. Other examples of applications programs are HP VEE from Hewlett-Packard and DasyLab from DasyTec GMBH, among others. These application programs provide a user with the tools to control instruments, including acquiring data, analyzing data, and presenting data.
The application programs mentioned above typically operate in conjunction with one or more instrument drivers to interface to actual physical instruments. For example, the LabVIEW and LabWindows application software each include instrument libraries comprising drivers for more than six hundred GPIB, VXI, and RS-232 instruments from numerous manufacturers. The instrument drivers are designed to reduce a user""s application development time by providing intuitive high level functions that relieve the user of complex low level instrument programming.
A software level referred to as driver level software is below the instrument driver level. Driver level software is used to interface the commands in the instrument driver to the actual hardware interface being used, such as a GPIB interface card, a data acquisition card, or a VXI card. In other words, driver level software handles the details of communication, i.e., the transfer of commands and data, over a physical connection between the computer and instruments. There have been many implementations of I/O control software, some of which were custom-developed by end users, while others were developed by vendors and sold along with interface hardware. Examples of driver level software include NI-488, NI-DAQ, and NI-VXI driver level software offered by National Instruments, Inc., which have become de facto standards in the industry. Another example of driver level software is the Standard Instrument Control Library (SICL) offered by Hewlett-Packard and the VISA (Virtual Instrument Software Architecture) promulgated by the VXIplugandplay Consortium.
FIG. 1 illustrates the historical evolution of instrument drivers. When IEEE 488.1 instruments were first introduced, standardized I/O libraries were provided which allowed users to provide strings to instruments. These standardized libraries include libraries for IEEE 488.1, IEEE 488.2 and the VISA I/O libraries. The progression from IEEE 488.1 to IEEE 488.2 and then to VISA represent a progression or evolution of the I/O libraries and how the user communicates with an instrument. However, each of these libraries generally still required the user to understand command strings and/or what registers were required to peek and poke within an application to control an instrument.
After the introduction of standardized I/O libraries, there was a movement to standardize the commands that users provided to instruments. This standardization of commands was referred to as SCPI (Standard Commands for Programming Instruments). SCPI allowed generic applications that worked with any of a plurality of instruments. In other words, each of the instruments accepted the same commands and behaved generically based on those commands. However, SCPI did not provide a sufficient number of commands to cover all the different types of instruments available.
During this time, companies such as National Instruments and Hewlett Packard, among others, have been developing instrument drivers. Instrument drivers are custom written libraries of software that are specific to a given instrument. These instrument drivers encapsulate, at a high level, the commands that are required to communicate to a given instrument. These instrument drivers encapsulate all of the low level syntax and the order of operation that is required to send commands to an instrument, which can be very difficult and time consuming.
Examples of current prior art instrument drivers are those developed for LabVIEW and LabWindows/CVI. These instrument drivers present the user with a set of high level functions that are easy to understand and use in their programs. The VXIplugandplay consortium was formed to extend these instrument drivers. The VXIplugandplay standard ensured that the user could install instrument drivers from a variety of vendors on one computer, and those instrument drivers would not conflict with each other. In other words, instrument drivers which conformed to the VXIplugandplay standard would behave gracefully in a system comprising a plurality of instrument drivers supplied by a variety of vendors, thus providing system interoperability. However, the VXIplugandplay instrument drivers did not address other high level system issues, such as state caching, simulation and instrument interchangeability, among others.
A primary problem with the traditional software architecture for an instrumentation system is that a separate instrument driver is required for each specific instrument. In addition, the user is required to include certain instrument driver specific commands in an application program. Thus, when a user creates an application program using an instrument of a certain class, if the user later desires to use a different instrument of that same class, such as instrument from a different vendor, or if the user desires to use an instrument of that same class but having a different hardware interface type, the user is required to modify the application program and then recompile the program.
Therefore, it would be highly desirable for instrument driver software to be independent or generic with respect to a certain class of instruments. In other words, when a user writes a software application to control a specific instrument of a first class, it would be desirable for the software application to control all instruments of that first class, such as instruments supplied from different vendors or with different hardware interface types. It would further be desirable to provide other high level instrument driver features, including state caching, simulation, verification of replacement instruments, and an attribute model.
Therefore, an improved system and method is desired for controlling instrumentation systems and for providing a user or developer with the capability to develop instrument drivers and application software for controlling instrumentation systems. An instrument driver software architecture is further desired which allows the use of generic instrument drivers and provides enhanced features.
The present invention comprises a system and method for controlling an instrumentation system, wherein the present invention includes an improved instrument driver software architecture. The instrument driver software architecture of the present invention provides a number of features, including instrument interchangeability, i.e., the use of interchangeable virtual instruments or interchangeable instrument drivers, improved performance, an improved attribute model, improved range checking, and improved simulation features, among others.
The instrumentation system comprises a computer system including a CPU and memory and at least one instrument coupled to the computer system. The instrument includes a plurality of settings which indicate a state of operation of the instrument.
The memory of the computer system stores a user application which performs an application using the instrument. The memory also stores a specific instrument driver which controls the instrument, wherein the specific instrument driver includes a plurality of functions which control operation of the instrument. The specific instrument driver includes a plurality of attributes which model the attributes or settings of the instrument. If the system includes a plurality of instruments, the memory preferably stores a specific i.d. for each instrument.
In the preferred embodiment, the instrument is of an instrument class, such as DMM, scope, etc. The memory of the computer system preferably stores a class driver which is generic to instruments of the respective class. Thus the class driver incorporates capabilities or functions which are generic or common to instruments of the respective class, and the class driver operates with substantially all instruments of the respective class. For example, the instrumentation system includes a class driver which is generic to all DMMs (digital multimeters), a class driver which is generic to oscilloscopes, etc. The class driver operates for any instrument within the class of instruments regardless of manufacturer or hardware interface type.
The memory of the computer system also stores an interchangeable virtual instrument (IVI) engine. The IVI engine operates as a support library to each of the class drivers. Thus, the IVI engine is generic to each of the class drivers, and provides services to each of the class drivers. The IVI engine includes one or more set attribute functions for setting attributes in the instrument and includes one or more get attribute functions for obtaining values of attributes from the instrument. The set attribute functions and the get attribute functions in the IVI engine are common for each of the class drivers and specific instrument drivers.
The memory of the computer system further stores an initialization (INI) file which includes configuration information for a virtual instrument, wherein the virtual instrument includes the instrument and the specific driver. The INI file specifies the name and location of the specific driver and the address of the instrument as well as other information regarding the virtual instrument. According to the present invention, the user is generally required only to change configuration information in the INI file in order to replace instruments of a class or change functionality of the virtual instrument.
The user application includes an initialization (init) function call to the class driver which initializes the class driver and the specific driver. After the single init call, the user application can make calls to functions in the class driver or the specific driver. The user application preferably makes calls to the class driver. All the functions in the class driver are generic functions, i.e., functions which are common to all or most of the specific drivers within the class. This provides the instrument interchangeability benefits of the present invention. The user application can also make calls to generic functions directly to the specific driver. The user application can further make calls to unique functions, also referred to as instrument-specific functions, i.e., functions which are not generic to the class and hence do not reside in the class driver, directly to the specific driver.
When the class driver receives a function call from the user application, the class driver obtains a function pointer from the IVI engine. The class driver uses the pointer to invoke the corresponding function in the specific instrument driver. Functions in the specific driver perform operations on the respective instrument. The functions include calls to VISA to communicate directly with the instrument and/or they include calls to the set attribute functions and/or get attribute functions in the IVI engine, which operate to set and get attributes in the specific driver.
The set and get attribute functions perform a standard set of operations. These operations include range checking, coercion of attribute values, state caching, writing a setting to the instrument, reading a setting from the instrument, and checking the instrument status. To perform these operations, the set and get attribute functions access range tables provided by the specific instrument driver and invoke callback functions in the specific instrument driver.
As noted above, the specific driver includes attributes which model attributes or settings of the instrument. The specific driver also includes attributes referred to as development/production attributes, such as state caching, interchangeability checking, range checking, instrument status checking, and coercion recording. The INI file stores the attribute values for the virtual instrument, and the IVI engine is operable to examine the initialization file and configure the attributes in the specific driver with attribute settings from the INI file. According to the present invention, the initialization (INI) file is operable to be configured with these development/production attributes in a development mode during development of the user application. The initialization (INI) file is operable to be configured with these development/production attributes in a production mode during production of the user application. In other words, during development and testing of the system, the user can configure the INI file with these attributes in a mode for testing and development, e.g., state caching disabled, and interchangeability checking, range checking, instrument status checking, and coercion recording enabled for debugging purposes. After development has been completed, the user can configure the INI file with these attributes in a mode which provides increased performance, such as enabling state caching, and disabling interchangeability checking, range checking, instrument status checking, and coercion recording.
Each class of instruments includes one or more of three types of attributes and fimctions, these being fundamental, extension and instrument-specific. Fundamental attributes and functions are those which are generic or fundamental to the class of instruments, i.e., all or most instruments of the class have each of the fundamental attributes and functions. Accordingly, the class driver and each of the specific drivers are required to include each of the fundamental attributes and functions. Extension attributes and functions are those which are generic or common to a subset, but not all, of the instruments of the class. Extension attributes and functions are required to be in the class driver and are included in some specific drivers, but are not required in all specific drivers. Instrument-specific attributes and functions are those which are specific to only one or more instruments of the class. Instrument-specific attributes and functions are not included in the class driver, and are included in only the specific drivers corresponding to the one or more instruments which support the instrument-specific attributes and functions.
Capability groups are groups of related functions and attributes. There are two types of capability groups, these being the fundamental capabilities group and extension groups. Each class of instruments contains one fundamental capabilities group. The fundamental capabilities group contains all of the fundamental functions and fundamental attributes. Extension groups are groups of related extension functions and extension attributes. If a specific driver implements any of the functions or attributes of an extension group, the specific driver must implement all of the functions and attributes that the extension group contains.
The present invention provides a feature referred to as instrument interchangeability, meaning that once an application is created for an instrumentation system using a specific instrument of a first class, wherein the application was created using a class driver which is generic to the first class, the user can readily substitute other instruments of the first class without modifying the user application. Rather, the user is required only to change configuration information in the INI file to interchange instruments of a class.
The class driver of the present invention also performs instrument interchangeability checking when a function call is received to verify that an instrument is in an interchangeable state. Thus, when the class driver receives a function call which causes the instrument to perform a function based on a current configuration of the instrument, the class driver performs instrument interchangeability checking. In the preferred embodiment, instrument interchangeability checking includes first determining if fundamental attributes which will affect instrument behavior in the current configuration are in a user-specified state, i.e., the application program took explicit actions to set the states of the attributes. If one or more fundamental attributes which will affect instrument behavior in the current configuration are not in a user-specified state, the class driver records an error.
The class driver then determines which extension groups have extension attributes that have ever been in a user-specified state. If an extension group contains attributes which have ever been in a user-specified state and also contains one or more attributes that will affect instrument behavior but which are not currently in user-specified state, the class driver records an error.
The class driver also determines if one or more extension groups have never been in a user-specified state and are implemented in the specific driver. If all of the extension attributes of one or more extension groups have never been in a user-specified state and are implemented in the specific driver, the class driver sets all the extension attributes that are in the groups and that will affect instrument behavior to default values, thereby placing the instrument in an interchangeable state.
In order to ensure instrument interchangeability, the user preferably creates the initialization file to include default values of the instrument-specific attributes of the virtual instrument. Thus, when the user application makes a call to the initialization function in the class driver to control the instrument, the class driver sets the instrument-specific attributes to the default values according to the information in the initialization file. Thus the user can replace the instrument with a second instrument of the same class, wherein the replacement does not require any modifications to the user application, but rather only requires changing a portion of the initialization file to include different default values for the instrument-specific attributes.
The present invention thus provides an instrument driver software architecture which provides a number of features and benefits. The system includes an attribute model which provides improved performance over prior systems. The present invention also provides features such as state caching for improved performance, simulation features, development/production modes, instrument interchangeability, interchangeability checking and verification of replacement instruments. Therefore, the present invention comprises a system and method for controlling an instrumentation system. The present invention allows for greater flexibility and greater reusability of code as well as simplified driver and/or application development.